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Abstract 


A method for converting data formats which differ from one another during exchange of messages or data 
between programs running on different processors of a communication system provides that a conversion 
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(54) Verfahren zum Konvertieren sich unterscheidender Datenformate 



(57) Der Austausch von Nachrichten oder Daten 
zwischen, auf unterschiedlichen Prozessoren eines f\Q 2 

Kommunikationssystems ablaufenden Programmer) ist 
insofern problematisch, als daB unter Umstanden sich 
unterscheidende Datenformate, wie zum Beispiel das 
Big-Endian-Format Oder das Little-Endian-Format, ver- 
wendet werden. Das erfindungsgemaBe Verfahren 
schafft hier Abhilfe, indem bereits wahrend des Uber- 
setzungsvorganges der Quellprogramme eine Kbnver- 
tierungsprozedur pro Datentyp generiert wird, die 
wahrend des spateren Ablauts der ProzeBe und Pro- 
gramme unmittelbar vor dem Nachrichtenaustausch die 
Konvertierung der Datenformate steuert. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren gemflB Oberbe- 
griff des Patentanspruchs 1 . 

ZeitgemaBe Kommunikationssysteme sind als Mul- s 
tiprozessorsysteme ausgebildet. Dies bedeutet, daft 
eine Vielzahl von Prozessoren die Steuerung der 
systeminternen Vorgange durchfuhren. In der Regel 
sind derartige Kommunikationssysteme als heterogene 
Systeme ausgebildet. Dies bedeutet, daB Prozessoren 10 
verschiedener Hersteller im Kbmmunikationssystem 
eingesetzt werden. Damit arbeiten aber diese Prozes- 
soren auch nach herstellerspezrfischen Standards. So 
werden beispielsweise Daten von den einzelnen Pro- 
zessoren in unterschiedlichen Formaten im jeweils 75 
zugeordneten Speicher abgelegt. Dies bedeutet 
solange keine Einschrankung des Betriebes, solange 
Programme, die in der Regel wahrend ihres Ablaufes 
jeweils einem Prozessor zugeodnet sind, diese Daten 
aus dem betreffenden Speicher auslesen.verarbeiten 20 
und wieder in den Speicher einschreiben, da in diesem 
Fall stets dasselbe Datenformat verwendet wird. Pro- 
bleme entstehen meist dann, wenn Nachrichten Oder 
Daten zwischen Prozessoren bzw. auf diesen ablaufen- 
den Programmen ausgetauscht werden, da hier gege- 25 
benenfalls diese Daten an die unterschiedlichen 
Datenformate angepaBt werden mussen. 

So werden beispielsweise Daten, die auf Prozesso- 
ren der Motorola-Familie verarbeitet werden, von diesen 
in einem LSBJHI-Format (Least Significant Byte at 30 
Highest Address), auch Big-Endian-Format genannt, 
abgelegt. Im Gegensatz dazu werden Daten, die auf 
Prozessoren der Intel- Familie verarbeitet werden, von 
diesen in einem LSB_LO-Format (Least Significant 
Byte At Lowest Address),auch Little-Endian-Format 35 
genannt, abgelegt. Damit mussen nun im Falle eines 
Datenaustausches zwischen diesen beiden Prozessor- 
typen die Daten in entsprechender Weise konvertiert 
werden. 

Zur LOsung derartiger Probleme hinsichtlich unter- 40 
schiedlicher Datenformate bei der ProzeBkommunika- 
tion in heterogenen Systemen wurde bisher ein 
spezielles Transferformat fur den Austausch von Nach- 
richten und Daten festgelegt. Dies bedeutet, daB gene- 
rell vor jedem Nachrichtenaustausch das prozess- 45 
oreigene Format in ein vomer festgelegtes. lediglich 
zum Zwecke des Austausches von Nachrichten verwen- 
detetes Ubertragungsformat umgewandelt wird. 1st die 
Nachricht beim Zielprozessor angekommen.wird das 
Ubertragungsformat in das dort verwendete prozessor- so 
eigene Format zurOckverwandelt. Zu diesem Zweck 
wird beim Stand der Technik eine Bibliothek zur Verfu- 
gung ge stellt, die Konvertierungsfunktionen fur die . 
Basisdatentypen derjeweiligen Programmiersprache 
enthalt. Mit Hiffe dieser Formatkonvertierungen kflnnen 55 
dann die Ubertragungsformate beim Austausch von 
Nachrichten zwischen Prozessoren festgelegt werden. 

Weiterhin kflnnen bei verschiedenen Programmier- 
sprachen wie beispielsweise CHILL vom Entwickler der 



Applikationssoftware Datenformate festgelegt werden, 
unter denen Daten abgespeichert werden. Diese Ver- 
haltnisse sind in "Language Solution for Mixed Data 
Formats, Mark Clark, G. Walter, fourth CHILL Confe- 
rence, MOnchen 29.9. - 2.10.1986" dargelegt 

Problematisch an einer derartigen Vorgehensweise 
ist, daB die durch den Austausch von Nachrichten mit- 
einander kommunizierenden Programme jeweils selbst 
fur die Konvertierung der auszutauschenden Nachrich- 
ten zwischen prozessoreigenem Datenformat und 
Transferformat verantwortlich sind. Damit mussen aber 
alie benfltigten Format-Kbnvertierungen vom Entwickler 
der Applikationssoftware bei der Codierung des jeweili- 
gen Programmes explizit programmiert werden. insbe- 
sondere sind Konvertierungen komplexer Datentypen 
(Strukuren, Arrays) explizit auf die durch die Biblio- 
theksfunktionen unterstutzten Konvertierungen der 
Basisdatentypen abzubilden. Damit ist zwangslaufig 
sowohl ein erhflhter Entwicklungsaufwand als auch eine 
zusatzliche Fehlerquelle verbunden.Weiterhin besteht 
bei strikter Anwendungn dieser Technik das Problem, 
daB auch beim Versenden von Nachrichten zwischen 
Programmen.die auf Prozessoren mit ein- und demsel- 
ben Datenformats ablaufen, die Konvertierungen vom 
prozessoreigenen Datenformat des Quellenprozessors 
in das Ubertragungsformat und aus dem Ubertragungs- 
format in das prozessoreigene Datenformat des Ziel- 
prozessors erfolgen. Dadurch wird die Dynamik des 
Systems beeintrachtigt. 

Der Erfindung liegt die Aufgabe zugrunde, einen 
Weg aufzuzeigen, wie die Konvertierung von Datenfor- 
maten beim Austausch von Nachrichten oder Daten 
zwischen Prozessoren, in denen jeweils unterschiedli- 
che Datenformate verwendet werden, ohne einen 
Dynamikverlust des Systems bei reduzierter Fehleran- 
falligkeit gestaltet werden kann. 

Vorteilhaft an der Erfindung ist, daB bereits wah- 
rend des Ubersetzungsvorgangs der Quellprogramme 
automatisch die fur die Konvertierung der Daten zwi- 
. schen den Formaten nfltigen Prozeduren bereitgestellt 
werden. Dies wird erreicht, indem das Ubersetzungs- 
programm nach MaBgabe der in den Quellprogrammen 
verwendeten Datentypen tonvertierungsprozeduren 
wahrend des Obersetzungslaufes erzeugt, die dann 
wahrend des spateren Ablaufs der Obersetzten Pro- 
gramme vor dem Nachrichtenaustausch aufgerufen 
werden. Damit ist der Vorteil verbunden, daB der Ent- 
wickler keinerlei explizite Vorsorgefurdie Konvertierung 
der Daten in der Applikationssoftware mehr vornehmen 
muB. Damit entfallt neben dem erhOhten Entwicklungs- 
aufwand auch diese zusatzliche Fehlerquelle. 

Weitere Ausgestaltungen der Erfindung sind in den 
Unteranspruchen gegeben: 

GemaB Anspruch 2 ist vorgesehen, daB die Kon- 
vertierungsprozedur als Sourcecode generiert wird, der 
in einem gesonderten Obersetzungslauf in den ablauf- 
fahigen Objektcode uberfuhrt wird. 

GemaB Anspruch 3 ist vorgesehen.daB bei mehr- 
maligem Auftreten desgleichen Datentyps fur die zu 
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uberfuhrenden Daten in einem Programm lediglich eine 
Konvertierungsprozedur generiert wird. Damit ist der 
Vorteil der Einsparung von Zeit bei der Obersetztung 
des Quellprogramms und von Speicherplatz verbunden. 

GemaB Anspruch 4 ist vorgesehen, daB im Fa lie, 
da 3 Daten zwischen Prozessoren mit gleichem Daten- 
format ausgetauscht werden, keine Konvertierungspro- 
zedur generiert wird. Dies wird durch die explizrte 
Markierung der entsprechenden Datentypen im Quell- 
programm mit dem passenden Datenformat erzwun- 
gen. Damit ist der Vorteil einer erhOhten Dynamik des 
Systems verbunden. 

Die Erfindung wird im folgerden anhand eines Aus- 
fuhrungsbeispiels naher eriautert. 

Es zeigen: 

Figur 1 die im Kommunikationssystem verwende- 
ten unterschiedlichen Datenformate am 
Beispiel des Basisdatentyps INTEGER 

Figur 2 das erf indungsgemSBe Verfahren. 

Figur 1 zeigt sich unterscheidende Datenformate, 
wie sie von den Prozessoren eines Kommunikationssy- 
stems beim Abspeichern verwendet werden. Dabei ist 
gemafi Fig. 1a das Big-Endian-Format aufgezeigt. Bei- 
spielhaft sind hier vier Bytes, namlich Byte 0, Byte 1, 
Byte 2, Byte 3 dargestellt. Jedes Byte weist jeweils acht 
Bit auf. Die Signifikanz der Bits wird beginnend mit Bit 0 
von Byte 3 in aufsteigender Reihenfolge bis zu Bit 7 von 
Byte 0 def iniert. Als Beispiel ist weiterhin aufgezeigt, wie 
die dezimale Zahl 1 in diesem Format darstellbar ist. Sie 
wird realisiert, indem das niederwertigste Bit, namlich 
Bit 0 des Byte 3 gesetzt wird. 

GemaB Fig. 1b ist das Littie-Endian- Format aufge- 
zeigt. Hier ist die Signifikanz der Bits in der dort aufge- 
zeigten Reihenfolge definiert. Als Beispiel wird die 
dezimale Zahl 1 definiert, indem das niederwertigste 
Bit, namlich Bit 0 des Byte 0 gesetzt wird. Aus diesem 
Beispiel ergibt sich die unterschiedliche Definition bei- 
der Datenformate, sowie die Notwendigkeit einer 
Anpassung beider Datenformate beim Datenaustausch. 

GemaB Fig. 2 wird das erfindungsgemaBe Verfah- 
ren eriautert. Dabei wird davon ausgegangen, daB die 
Konvertierungsvorgange automatisch von einem Uber- 
setzungsprogramm COMP wahrend des Obersetzungs- 
vorgangs gesteuert werden. Somit muG wahrend der 
Codierungsphase keinerlei Vorsorge getroffen werden, 
wie und in welcher Weise die Konvertierung der Daten- 
formate erfolgen soil. Weiterhin wird davon ausgegan- 
gen, daB ein zu ubersetzendes Programm P sich 
unterscheidende Datentypen aufweist. Beispielhaft sol- 
len dies die Datentypen D 1( D 2 , und D 3 sein. Fur das 
erfindungsgemaBe Verfahren relevant sind komplexere 
Datentypen wie Strukturen Oder Felder (Arrays), die es 
zu konvertieren gilt Weiterhin wird in vorliegendem 
Ausfuhrungsbeispiel davon ausgegangen, daB ein 
Datentyp. namlich der Datentyp D 1t im Programm P 
mehrmals auftritt. 



Wahrend des Obersetzungsvorgangs werden unter 
der Steuerung des Ubersetzungsprogramms COMP die 
Stellen im Code des Programms P. an denen Nachrich- 
ten zu anderen Programmen wahrend des spateren 

5 Ablaufs gesteuert werden speziell behandelt. Es wird 
der Datentyp der Nachricht ermittert, und im folgenden 
eine fur die UberfOhrung dieses Datentyps. in das 
Datenformat des Zielprozessors adequate Konvertie- 
rungsprozedur generiert. GemaB Rg.2 ist dies fur den 

10 Datentyp 0^ die Konvertierungsprozedur KON v Die 
Prozedur selbst wird im Sourcecode unter einem defi- 
nierten Prozedurnamen abgelegt. AnschlieBend wird 
vor dem den Nachrichtenaustausch bewerkstelligenden 
Befehl der Aufruf dieser Konvertierungsprozedur einge- 

75 tragen. Im folgenden tritt der Datentyp jedoch noch 
. zweimal auf. Beim erneuten Auftreten dieses Datentyps 
als Nachricht wird keine erneute Generierung der Kon- 
vertierungsprozedur KONt vorgenommen. Lediglich der 
Prozeduraufruf wird an den betreffenden Stellen einge- 

20 fOgt. 

GemaB Fig. 2 treten im folgenden die Datentypen 
D 2l D 3 als Nachrichten auf. Insofern mQssen nun auch 
weitere, sich von der Konvertierungsprozedur KO^ 
unterscheidende Konvertierungsprozeduren generiert 

25 werden. In vorliegendem Ausfuhrungsbeispiel sollen 
dies die Konvertierungsprozeduren KON 2 , KON 3 sein. 
Die Konvertierungsprozedur wird also durch den Daten- 
typ def iniert. Dem Datentyp D 2 wird somit die Konvertie- 
rungsprozedur KON 2 und dem Datentyp D 3 die 

30 Konvertierungsprozedur D 3 zugeordnet. 

Beim spateren Ablauf des in den Objektcode uber- 
fuhrten Programmes P werden somit unmittelbar vor 
dem Nachrichtenaustausch Aufrufe der betreffenden 
Konvertierungsprozeduren durchgefuhrt. Damit werden 

35 die zu ubertragenden Daten in diejweiligen Datenfor- 
mate des Zielprozessors umgewandelt. 

In einer Ausgestaltung der Erfindung wird vorgese- 
hen, daB fur die Nachrichten, die zwischen ProzeBen 
ausgetauscht werden, die dasselbe Datenformat ver- 

40 wenden, vom Ubersetzungsprogramm COMP keine 
Konvertierungsrozedur generiert wird. 

Das vorstehend geschilderte Ausfuhrungsbeispiel 
bescheibtden Nachrichtenaustausch zwischen Prozes- 
soren mit sich unterscheidenden Formaten zum 

45 Abspeichern von Daten. Die Erfindung ist jedoch nicht 
auf dieses Ausfuhrungsbeispiel beschrankt. 

In einer weiteren Ausgestaltung wird vorgesehen, 
daB generell unterschiedliche Datenformate in einem 
Programm verwendet werden kflnnen. So lassen einige 

so Programmiesprachen wie z.B. CHILL die explizite 
Angabe eines Datenformates durch den Programmierer 
zu. Dieses durch den Programmierer erzwungene For- 
mat kann sich durchaus von den prozessoreigenen For- 
maten unterscheiden. Wahrend des Ubersetzungs- 

55 vorganges werden dann in oben angesprochenen 
Weise Konvertierungsprozeduren generiert und aufge- 
rufen. 
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Patentanspruche 

1 . Verfahren zum Konvertieren sich unterscheidender 
Datenformate, mit Programmen (P), die ats Ergeb- 
nis eines durch ein Ubersetzungsprogramm 5 
(COMP) gesteuerlen Ubersetzungsvorgang in 
einen ablauff&higen Objektcode uberfuhrbar sind, 
und die gegebenenfalls unterschiedliche Daterrty- 
pen aufweisende Daten bearbeiten, wobei letztere 
von einem ersten Format in ein zweites Format 10 
OberfQhrbar sind 

dadurch gekennzeichnet, 
daB unter der Steuerung des Ubersetzungspro- 
gramms (COMP) beim Clbersetzungsvorgang der 
Daterttyp der zu QberfQhrenden Daten ermittelt is 
wird, woraufhin eine, diesem Datentyp adaquate 
Konvertierungsprozedur (KON^-KON^ generiert 
wird, und dem den Uberfuhrungsvorgang bewerk- 
stelligenden Befehl ein Aufruf der betreffertden 
Konvertierungsprozedur (KON v . KON^vorange- 20 
stellt wird. 

2. Verfahren nach Anspruch 1 
dadurch gekennzeichnet, 

daB Konvertierungsprozedur (KON v ..KON 3 ) als 25 
Sourcecode generiert wird. der in einem gesonder- 
ten Obersetzungslauf in den ablauffdhigen Objekt- 
code uberfuhrt wird. 

3. Verfahren nach 1 oder 2, 30 
dadurch gekennzeichnet, 

daB bei mehrmaligem Auftreten desgleichen 
Datentyps f Qr die zu QberfQhrenden Daten in einem 
Programm (P) lediglich eine Konvertierungsproze- 
dur generiert wird. 35 

4. Verfahren nach Anspruch 1 bis 3, 
dadurch gekennzeichnet, 

daB im Falle, daB Daten zwischen Prozessoren mit 
gleichem Datenformat ausgetauscht werden, keine 40 
Konvertierungsprozedur generiert wird. 
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FIG 1b 
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